QMT 与 PTrade · 券商量化交易终端梳理

0. 一句话结论

QMT 是"本地客户端 + Python 库"的可编程交易终端，PTrade 是"跑在券商机房的托管式策略平台"。功能覆盖高度重合（A 股股票 / 两融 / ETF / 期货 / 期权、回测、实盘），真正的分野在运行位置：QMT 策略跑在你自己的电脑或云服务器上，自由度高、可用任意三方库，但依赖本地机器与网络；PTrade 策略托管在券商机房，无人值守、稳定低延迟，但内网隔离、只能用它内置的库，且编辑环境锁定 Windows。二者都是券商采购后免费（或按资金门槛）提供给客户的工具，没有绝对优劣，只看你的开发习惯与部署诉求。

1. 平台背景与定位

1.1 两个平台分别是什么

1.2 最本质的差异：运行位置

把两个平台放在同一张图上看，全部差异几乎都能从"策略代码到底跑在哪台机器上"这个原点推导出来：

• QMT：策略在你的机器上运行，通过本地通信连到 MiniQMT 客户端，再由客户端连券商柜台。好处是环境自由（可 pip 任意库、可调试、可接自有数据源），代价是机器要常开、断网即中断。
• PTrade：策略代码提交到券商机房，由 PTrade 引擎按事件周期驱动执行。好处是稳定、低延迟、真正无人值守，代价是内网隔离（不能上网、不能 pip）、只能用内置库、编辑环境受限。

2. 行为视图（系统做什么）

先看"做什么"：从整体用例，到策略全生命周期，再分别拆解两个平台一次下单的完整链路，最后收束到委托单的状态流转。

2.1 用例图 · 量化终端整体行为

图 1 用例图（行为 · 整体）：量化投资者、券商与交易所围绕量化终端的核心用例

两个平台对投资者呈现的用例几乎一致：编写调试、历史回测、仿真交易、实盘自动交易、行情获取、账户查询、风控、监控。区别在于用例的执行方与承载位置——QMT 的"策略编写 / 回测 / 实盘"发生在本地，PTrade 的则发生在券商机房内。

2.2 活动图 · 策略全生命周期

图 2 活动图（行为 · 主流程）：从研究编写到实盘运行的策略生命周期，含回测 / 仿真两道闸门

无论用 QMT 还是 PTrade，量化策略的落地路径是同一条：研究 → 回测 → 仿真 → 实盘 → 监控迭代。两个平台在"仿真"这一步的实现方式不同：QMT 常以模拟账号 / 模拟柜台完成，PTrade 有独立的仿真交易环境。回测与仿真未达标就实盘，是量化最常见的亏损来源。

2.3 时序图 · QMT 实盘下单链路

图 3 时序图（行为 · 细化）：QMT 中一次报单从策略进程到交易所的往返

QMT 的链路是"策略进程 → xtquant → MiniQMT 客户端 → 券商柜台 → 交易所"。策略侧既可用同步接口 order_stock（返回订单号），也可用异步接口 order_stock_async（返回请求序号），成交与状态变化通过注册的回调类主推回策略。下面是最小可运行的连接 + 下单示例：

from xtquant.xttrader import XtQuantTrader, XtQuantTraderCallback
from xtquant.xttype import StockAccount
from xtquant import xtconstant

class MyCallback(XtQuantTraderCallback):
    def on_stock_order(self, order):
        print("委托回报:", order.stock_code, order.order_status)
    def on_stock_trade(self, trade):
        print("成交回报:", trade.stock_code, trade.traded_volume, trade.traded_price)
    def on_order_error(self, err):
        print("下单失败:", err.order_id, err.error_msg)

path = r"D:\迅投极速交易终端\userdata_mini"   # MiniQMT 的 userdata_mini 目录
trader = XtQuantTrader(path, session_id=123456)
acc = StockAccount("1000000365")               # 资金账号
trader.register_callback(MyCallback())
trader.start()
trader.connect()                               # 返回 0 表示连接成功
trader.subscribe(acc)                          # 订阅交易主推

# 同步报单：指定价买入 600000.SH 200 股
order_id = trader.order_stock(
    acc, "600000.SH", xtconstant.STOCK_BUY, 200,
    xtconstant.FIX_PRICE, 10.5, "my_strategy", "remark")

trader.run_forever()                           # 阻塞线程，持续接收主推

行情侧由 xtdata 模块独立提供，可取历史与实时行情、分笔、财务、板块数据：

from xtquant import xtdata

# 先下载再读取，避免实时拉取阻塞
xtdata.download_history_data("600000.SH", "1d", "20240101", "20241231")
bars = xtdata.get_market_data_ex([], ["600000.SH"], period="1d")
print(bars["600000.SH"].tail())

2.4 时序图 · PTrade 实盘下单链路

图 4 时序图（行为 · 细化）：PTrade 托管策略由引擎按事件周期驱动下单

PTrade 没有"策略进程"这一显式概念，取而代之的是引擎按周期调用你写好的事件函数：initialize（启动一次）→ 每个交易日 before_trading_start → 盘中反复 handle_data / tick_data → after_trading_end。你在这些函数里调用 order 系列接口下单，成交回报通过 on_order_response / on_trade_response 回吐。

def initialize(context):
    g.security = "600570.SS"      # 恒生电子
    set_universe(g.security)      # 设置股票池，只能操作池内标的

def before_trading_start(context, data):
    log.info("盘前准备：%s" % g.security)

def handle_data(context, data):
    price = data[g.security]["close"]          # 当前周期收盘价
    if price > 20:
        order_target_value(g.security, 10000)  # 调整到目标市值买入

def after_trading_end(context, data):
    log.info("盘后结算")

order("600570.SS", 1000)                 # 按数量买入（负数为卖出）
order_target("600570.SS", 0)             # 调整到目标持仓数量（0 = 清仓）
order_value("600570.SS", 10000)          # 按金额买入
order_target_value("600570.SS", 50000)   # 调整到目标持仓市值
order_market("600570.SS", 1000, 0)       # 市价委托（第三参为市价类型）

2.5 状态机图 · 委托单状态流转

图 5 状态机图（行为 · 细化）：一张委托单从报送到终态的状态流转（对应 QMT order_status）

两个平台都维护一张委托单的生命周期状态。QMT 用 xtconstant.ORDER_* 常量表达，PTrade 用订单对象的 status 字段表达，语义基本一一对应。理解状态机是处理"撤单失败 / 部成待撤"等边界条件的前提。

3. 结构视图（由什么组成）

再看"由什么组成"：从宏观部署，到各自的组件，到 Python 包与 API 分类，最后落到核心对象类图。

3.1 部署图 · 本地 vs 托管

图 6 部署图（结构 · 宏观）：QMT 本地部署 与 PTrade 机房托管的节点与连接

部署差异决定了一切运维特性：QMT 的策略与数据都在本地节点，机器关机 / 断网即策略中断；PTrade 的策略与行情都在券商机房，处于内网，天然获得更稳定的网络与更低的柜台穿透延时。

3.2 组件图

图 7 组件图（结构 · QMT）：xtquant 库、MiniQMT 客户端与券商柜台 / 行情服务

图 8 组件图（结构 · PTrade）：终端内的策略引擎、回测 / 仿真、量化工具与券商侧行情 / 柜台

两者都由"策略层 + 引擎层 + 券商侧"三段构成。QMT 的引擎层是本地独立的 MiniQMT 客户端；PTrade 的引擎层与券商侧同处机房，边界更模糊。

3.3 包图 · Python 包结构

图 9 包图（结构 · QMT）：xtquant 的行情、交易、类型、常量四个子包

图 10 包图（结构 · PTrade）：策略 API 按设置、行情、交易、对象、计算工具分组

QMT 以 Python 库形式暴露 API，导入路径清晰（xtquant.xtdata / xtquant.xttrader 等）；PTrade 的 API 不是"导入的库"，而是预置在策略运行环境里的全局函数，按功能分组，直接调用即可。

3.4 类图 · 核心对象

图 11 类图（结构 · QMT）：XtQuantTrader、回调类与资产 / 委托 / 成交 / 持仓对象

图 12 类图（结构 · PTrade）：Context / Portfolio / Position / Order 等上下文对象

QMT 是"交易器 + 数据结构"范式：XtQuantTrader 提供方法，查询 / 下单返回 XtAsset / XtOrder / XtTrade / XtPosition 等对象，通过 XtQuantTraderCallback 接收推送。PTrade 是"上下文 + 全局函数"范式：所有函数在事件函数中直接调用，账户与持仓信息封装在 context（context.portfolio）里，跨事件的状态放在全局对象 g。

4. 能力横向对比

4.1 运行模式与部署

4.2 编程模型

4.3 行情能力

4.4 交易品种与业务

4.5 稳定性与适用人群

5. 申请门槛与开通流程

QMT 与 PTrade 都不是"下载即用"的公开软件，而是"券商采购 → 提供给开户客户"的通道型产品。能否开通取决于三件事：你开户的券商、你的账户资产、以及程序化交易报备是否合规。

5.1 开通条件构成

5.2 两个平台的申请差异

5.3 程序化交易报备（2024 起的新增门槛）

自 2024 年《证券市场程序化交易管理规定（试行）》及沪深北交易所配套细则施行后，程序化交易投资者须事先报备，内容包括账户信息、交易策略类型、最高申报速率、单日最高申报笔数等；达到高频标准的还需额外报告并可能被加收费用。开通 QMT / PTrade 时券商一般会一并协助完成报备，未报备即程序化下单可能被限制交易或处罚。

6. 超级量化如何对接 QMT / PTrade

6.1 有没有交易 API：一张表说清

一句话：两者都不是"注册个 API key 就能远程下单"的开放接口。这是券商场的普遍特点——账户与执行必须落在用户自己已开通权限的终端里。也正因如此，"用户自持账户自跑"的工具定位天然成立、合规风险最低。

6.2 QMT 对接方案（推荐，可做到自动化）

QMT 是唯一能让超级量化程序化对接执行的通道。做法是把超级量化的"执行端 / 网关"部署到用户本机（或用户自购云主机），它 import xtquant，与用户已登录的 MiniQMT 客户端通信完成下单与回报。信号可由云端下发，执行器轮询后转为本地报单。

from xtquant.xttrader import XtQuantTrader, XtQuantTraderCallback
from xtquant.xttype import StockAccount
from xtquant import xtconstant
import requests  # 从超级量化云端拉取信号

class Gateway(XtQuantTraderCallback):
    def on_stock_trade(self, trade):
        report("trade", trade.stock_code, trade.traded_volume, trade.traded_price)

trader = XtQuantTrader(r"D:\...\userdata_mini", session_id=1001)
acc = StockAccount("1000000365")
trader.register_callback(Gateway())
trader.start(); trader.connect(); trader.subscribe(acc)

# 轮询超级量化云端信号 → 转成本地下单
for sig in requests.get("https://sq.example.com/api/signals",
                        params={"token": TOKEN}).json():
    if sig["action"] == "buy":
        trader.order_stock(acc, sig["code"], xtconstant.STOCK_BUY,
                           sig["volume"], xtconstant.FIX_PRICE, sig["price"],
                           "superquant", sig["id"])

trader.run_forever()

6.3 PTrade 对接方案（只能代码对接）

PTrade 没有任何外部可调用的交易接口，因此超级量化无法像 QMT 那样直接下单。可行做法是代码生成：把策略翻译成符合 PTrade 事件框架的 Python 文件，用户复制进 PTrade 客户端运行；若目标券商的 PTrade 支持外网 HTTP（少数），策略还可在运行时向超级量化拉取因子 / 信号数据，但下单动作仍只能发生在 PTrade 内部。

# 由超级量化自动生成，用户粘贴进 PTrade 客户端运行
def initialize(context):
    g.codes = ["600570.SS", "600519.SS"]
    set_universe(g.codes)

def handle_data(context, data):
    for code in g.codes:
        target = get_signal_from_superquant(code)   # 仅支持外网的券商可用
        if target is not None:
            order_target_value(code, target)

6.4 推荐架构：一套云端 + 两类执行端

图 13 部署图（对接 · 架构）：超级量化云端同时对接 QMT 本地执行器与 PTrade 代码导入

图 14 时序图（对接 · QMT）：云端信号经本机执行器转为 QMT 报单并回传成交

落地建议

• 加密市场：沿用现有 ccxt + API key 直连模式，与本文两个平台无关。
• A 股自动化：优先 QMT 通道——部署本地执行器，用户自持账户与 MiniQMT，超级量化只下发策略 / 信号。
• A 股信号：PTrade 走代码生成（用户手动运行），或继续用邮件信号（当前合规方案的选择）。
• 合规红线：不代客下单、不碰资金、不做收益承诺；执行器仅把用户自己的信号搬到用户自己的账户。

6.5 超级量化是 Web 应用，如何落地

Web 应用可以做，但不能是"纯浏览器 + 纯云端 SaaS"。根本原因还是那条硬约束：xtquant 必须与 MiniQMT 客户端同机运行，而浏览器沙箱不能直接执行本地 Python。Web 只能当交互层，用户侧仍必须有一个能跑 xtquant 的本地进程。由此有三种形态：

图 15 部署图（对接 · Web 形态）：浏览器 + 云端服务 + 用户侧本地执行器（agent）

要点：

• 本地进程是必需品——形态 A 是轻量 agent，形态 B 是整站后端，本质都是"用户侧要跑 xtquant"。
• 浏览器连本地：现代浏览器把 localhost 视为安全上下文，HTTPS 页面可访问 http://127.0.0.1；但更稳妥的是让本地 agent 反向连接云端（WebSocket 长连接），避免混合内容 / CORS / 防火墙问题。
• PTrade 仍不适用：Web 应用对 PTrade 只能"生成策略代码"，没有实时通道。
• 安全与合规：agent 仅监听本机、需用户显式授权与 token 鉴权；账户凭据不落云端；只把用户自己的信号搬到用户自己的账户——继续守住"工具"边界。

6.6 能否"一个账户 / 一个 QMT 服务所有用户"

这是个常见误区。答案分两层：技术上做不到，合规上不允许。

技术层面：权限按账户绑定

QMT / PTrade 的交易权限是绑在具体证券账户上的：xtquant 只能连本机已登录该账户的 MiniQMT，PTrade 策略也只能操作该券商给这个账户开通的权限。一个账户的终端无法合法地替其他用户的账户下单。

合规层面：这属于无牌经营 + 账户归集

第三方平台用一个账户替所有用户交易，等于代客下单 + 资金 / 证券归集，同时触碰多条红线：无牌经营证券业务、账户出借、场外配资、变相资金池，均属违法。

图 16 组件图（合规 · 边界）：合法的"持牌机构 + 账户分离" 与非法的"第三方单账户代所有用户"

合法的一对多模式确实存在，但主体是持牌方

7. 选型建议

8. 实战操作手册

8.1 QMT 从零到实盘

1. 开户与开通：在支持 QMT 的券商开户，向客户经理申请开通 QMT / MiniQMT 权限，确认资金门槛与佣金。
2. 安装客户端：下载券商的 QMT / 极速交易终端并安装，登录资金账号，记录安装目录下的 userdata_mini 路径。
3. 安装 xtquant：在本地 Python 环境放入 / 安装 xtquant 库（须与客户端版本匹配），确认 Python 版本在支持范围内。
4. 启动并连接：保持 MiniQMT 客户端登录运行；策略进程用 XtQuantTrader(path, session_id) → start() → connect()（返回 0）→ subscribe(acc)。
5. 行情与回测：用 xtdata.download_history_data 下载历史数据，在本地做回测与因子研究。
6. 仿真：用模拟账号连接，验证下单、撤单、查询、回调全链路。
7. 实盘运行：切换到实盘账号，run_forever() 接收主推；建议部署在同网云主机并加进程守护与日志监控。

asset = trader.query_stock_asset(acc)
print("可用:", asset.cash, "总资产:", asset.total_asset)

for p in trader.query_stock_positions(acc):
    print(p.stock_code, "持仓:", p.volume, "可用:", p.can_use_volume, "成本:", p.avg_price)

8.2 PTrade 从零到实盘

1. 开户与开通：在支持 PTrade 的券商开户，向营业部申请 PTrade 权限（部分券商提供测试账号）。
2. 下载安装：从券商官网下载对应券商的 PTrade 客户端（实盘版 / 测试版），安装并登录。
3. 新建策略：在策略列表新建策略，选择业务类型（如股票），基于模板编写 initialize + handle_data。
4. 新建回测：设定起止时间、初始资金、基准与频率（日线 / 分钟），保存后回测，查看收益曲线与评价指标。
5. 仿真 / 测试：用测试版或模拟客户端验证策略逻辑与下单链路。
6. 新建交易（托管）：在交易界面选中策略、命名并启动，策略即在券商机房按周期运行，可实时查看总资产、持仓与交易日志。
7. 持久化与监控：跨日状态用全局对象 g 保存（框架自动 pickle），如需可 send_email / send_qywx 推送告警。

def handle_data(context, data):
    pos = context.portfolio.positions          # 持仓字典
    cash = context.portfolio.cash              # 可用资金
    p = get_position("600570.SS")              # 单只持仓
    if p.amount > 0:
        log.info("持仓 %s 股，成本 %.2f" % (p.amount, p.cost_basis))

9. 参数指令速查手册

9.1 QMT · xtconstant 关键枚举

交易市场 market

委托类型 order_type（摘）

报价类型 price_type（摘）

委托状态 order_status

核心方法

9.2 PTrade · 关键函数与枚举

生命周期函数

设置与定时函数

行情与交易函数

代码尾缀

附录：资料来源

• 迅投知识库 · XtQuant 文档（快速开始 / XtData / XtTrader / 数据字典）：dict.thinktrader.net
• 迅投官网 ThinkTrader：thinktrader.net
• PTrade API 接口文档（含官方文档整理与示例）：ptradeapi.com
• 各支持券商（国金、国盛、湘财、东莞、长江、山西、申万宏源、国泰君安-海通等）官方客户端与开通说明

说明：本文技术细节以厂商公开文档为准；资金门槛、佣金、支持品种与接口版本以各券商实际规定为准。